ドメイン駆動設計：スケーラブルなソフトウェアのための境界づけられたコンテキストの習得

ドメイン駆動設計（DDD）は、コアとなるドメインに焦点を当てることで、複雑なソフトウェアプロジェクトに取り組むための強力なアプローチです。DDDの中心には、境界づけられたコンテキストの概念があります。境界づけられたコンテキストを理解し、効果的に適用することは、スケーラブルで保守可能、そして最終的に成功するソフトウェアシステムを構築するために極めて重要です。この包括的なガイドでは、境界づけられたコンテキストの複雑さに深く踏み込み、関連する戦略的および戦術的なパターンを探求します。

境界づけられたコンテキストとは？

境界づけられたコンテキストは、特定のドメインモデルの適用範囲を定義する、ソフトウェアシステム内の意味的な境界です。これは、特定の用語や概念が一貫した曖昧さのない意味を持つ、明確に定義されたスコープと考えることができます。境界づけられたコンテキスト内では、開発者とドメイン専門家が使用する共通の語彙であるユビキタス言語が明確に定義され、一貫しています。この境界の外では、同じ用語が異なる意味を持つか、まったく関連しない場合があります。

本質的に、境界づけられたコンテキストは、単一のモノリシックなドメインモデルが、複雑なシステムのために作成するには非現実的であるか、不可能でさえあることを認識しています。代わりに、DDDは問題ドメインをより小さく、管理しやすいコンテキストに分解することを提唱しており、それぞれが独自のモデルとユビキタス言語を持っています。この分解は、複雑さの管理、コラボレーションの改善、そしてより柔軟で独立した開発を可能にするのに役立ちます。

境界づけられたコンテキストを使用する理由

境界づけられたコンテキストを使用することには、ソフトウェア開発において数多くの利点があります：

• 複雑性の軽減：大規模なドメインをより小さく、管理しやすいコンテキストに分割することで、システム全体の複雑さを軽減します。各コンテキストはより簡単に理解し、保守することができます。
• コラボレーションの改善：境界づけられたコンテキストは、開発者とドメイン専門家間のより良いコミュニケーションを促進します。ユビキタス言語は、特定のコンテキスト内で全員が同じ言語を話すことを保証します。
• 独立した開発：チームは、お互いの邪魔をすることなく、異なる境界づけられたコンテキスト上で独立して作業できます。これにより、開発サイクルが高速化し、アジリティが向上します。
• 柔軟性とスケーラビリティ：境界づけられたコンテキストにより、システムの異なる部分を独立して進化させることができます。個々のニーズに基づいて特定のコンテキストをスケーリングできます。
• コード品質の向上：境界づけられたコンテキスト内で特定のドメインに焦点を当てることで、よりクリーンで保守しやすいコードにつながります。
• ビジネスとの整合性：境界づけられたコンテキストは、特定のビジネス機能や部門と整合することが多く、ソフトウェアをビジネスニーズにマッピングしやすくなります。

戦略的DDD：境界づけられたコンテキストの特定

境界づけられたコンテキストを特定することは、DDDにおける戦略的設計フェーズの重要な部分です。これには、ドメインを理解し、主要なビジネス機能を特定し、各コンテキストの境界を定義することが含まれます。以下に、段階的なアプローチを示します：

1. ドメインの探求：問題ドメインを徹底的に探求することから始めます。ドメイン専門家と話し、既存のドキュメントを確認し、関連する異なるビジネスプロセスを理解します。
2. ビジネス機能の特定：ソフトウェアシステムがサポートする必要があるコアビジネス機能を特定します。これらの機能は、ビジネスが実行する本質的な機能を表します。
3. 意味的な境界を探す：用語の意味が変わる領域や、異なるビジネスルールが適用される領域を探します。これらの境界は、しばしば潜在的な境界づけられたコンテキストを示します。
4. 組織構造の考慮：会社の組織構造は、潜在的な境界づけられたコンテキストに関する手がかりを提供することがよくあります。異なる部門やチームがドメインの異なる領域を担当している場合があります。「システムを設計する組織は、それらの組織のコミュニケーション構造のコピーである設計を生み出すように制約される」と述べるコンウェイの法則は、ここで非常に重要です。
5. コンテキストマップの描画：異なる境界づけられたコンテキストとその関係を視覚化するために、コンテキストマップを作成します。このマップは、異なるコンテキストがどのように相互作用するかを理解するのに役立ちます。

例：Eコマースシステム

大規模なEコマースシステムを考えてみましょう。これには、次のような複数の境界づけられたコンテキストが含まれる可能性があります：

• 製品カタログ：製品情報、カテゴリ、属性の管理を担当します。ユビキタス言語には、「製品」、「カテゴリ」、「SKU」、「属性」などの用語が含まれます。
• 注文管理：注文の処理、出荷の管理、返品の処理を担当します。ユビキタス言語には、「注文」、「出荷」、「請求書」、「支払い」などの用語が含まれます。
• 顧客管理：顧客アカウント、プロファイル、設定の管理を担当します。ユビキタス言語には、「顧客」、「住所」、「ロイヤルティプログラム」、「連絡先情報」などの用語が含まれます。
• 在庫管理：在庫レベルの追跡と在庫場所の管理を担当します。ユビキタス言語には、「在庫レベル」、「場所」、「発注点」、「サプライヤー」などの用語が含まれます。
• 決済処理：安全な決済処理と返金処理を担当します。ユビキタス言語には、「トランザクション」、「認証」、「決済」、「カード詳細」などの用語が含まれます。
• レコメンデーションエンジン：顧客の閲覧履歴や購入行動に基づいて製品レコメンデーションを提供する責任があります。ユビキタス言語には、「レコメンデーション」、「アルゴリズム」、「ユーザープロファイル」、「製品アフィニティ」などの用語が含まれます。

これらの境界づけられたコンテキストはそれぞれ、独自のモデルとユビキタス言語を持っています。たとえば、「製品」という用語は、製品カタログと注文管理のコンテキストで異なる意味を持つ場合があります。製品カタログでは、製品の詳細な仕様を指すかもしれませんが、注文管理では、単に購入される品目を指す場合があります。

コンテキストマップ：境界づけられたコンテキスト間の関係を視覚化する

コンテキストマップは、システム内の異なる境界づけられたコンテキストとその関係を視覚的に表現する図です。これは、異なるコンテキストがどのように相互作用するかを理解し、統合戦略について情報に基づいた決定を下すための重要なツールです。コンテキストマップは、各コンテキストの内部の詳細に踏み込むのではなく、それらの間の相互作用に焦点を当てます。

コンテキストマップは通常、境界づけられたコンテキスト間の異なる種類の関係を表現するために、異なる表記法を使用します。これらの関係は、しばしば統合パターンと呼ばれます。

戦術的DDD：統合パターン

境界づけられたコンテキストを特定し、コンテキストマップを作成したら、これらのコンテキストが互いにどのように相互作用するかを決定する必要があります。ここで戦術的設計フェーズが登場します。戦術的DDDは、境界づけられたコンテキストを接続するために使用する特定の統合パターンに焦点を当てます。

以下に、いくつかの一般的な統合パターンを示します：

• 共有カーネル：2つ以上の境界づけられたコンテキストが共通のモデルまたはコードを共有します。これは危険なパターンであり、共有カーネルの変更はそれに依存するすべてのコンテキストに影響を与える可能性があります。このパターンは控えめに使用し、共有モデルが安定していて明確に定義されている場合にのみ使用してください。たとえば、金融機関内の複数のサービスが、通貨計算のためのコアライブラリを共有する場合があります。
• 顧客-供給者：ある境界づけられたコンテキスト（顧客）が別の境界づけられたコンテキスト（供給者）に依存します。顧客は、そのニーズを満たすために供給者のモデルを積極的に形成します。このパターンは、一方のコンテキストが他方に大きな影響を与える必要がある場合に役立ちます。マーケティングキャンペーン管理システム（顧客）は、顧客データプラットフォーム（供給者）の開発に大きな影響を与える可能性があります。
• 適合者：ある境界づけられたコンテキスト（適合者）が、別の境界づけられたコンテキスト（上流）のモデルを単に使用するだけです。適合者は上流のモデルに影響を与えることはできず、その変更に適応しなければなりません。このパターンは、レガシーシステムやサードパーティサービスと統合する場合によく使用されます。小規模な販売アプリケーションは、大規模で確立されたCRMシステムによって提供されるデータモデルに単純に適合する場合があります。
• 腐敗防止層（ACL）：2つの境界づけられたコンテキスト間に位置し、それらのモデル間で変換を行う抽象化レイヤーです。このパターンは、ダウンストリームのコンテキストをアップストリームのコンテキストの変更から保護します。これは、制御できないレガシーシステムやサードパーティサービスを扱う場合に重要なパターンです。たとえば、レガシー給与システムと統合する際、ACLはレガシーデータ形式をHRシステムと互換性のある形式に変換できます。
• 分離された道：2つの境界づけられたコンテキストが互いに何の関連もありません。それらは完全に独立しており、個別に進化できます。このパターンは、2つのコンテキストが根本的に異なり、相互作用する必要がない場合に役立ちます。従業員向けの社内経費追跡システムは、一般向けのEコマースプラットフォームとは完全に分離して管理される場合があります。
• 公開ホストサービス（OHS）：ある境界づけられたコンテキストが、他のコンテキストがその機能にアクセスするために使用できる明確に定義されたAPIを公開します。このパターンは、疎結合を促進し、より柔軟な統合を可能にします。APIは、コンシューマーのニーズを考慮して設計されるべきです。決済ゲートウェイサービス（OHS）は、様々なEコマースプラットフォームが決済処理に使用できる標準化されたAPIを公開します。
• 公開言語：公開ホストサービスは、他のコンテキストと通信するために、明確に定義され文書化された言語（例：XML、JSON）を使用します。これにより、相互運用性が保証され、誤解のリスクが軽減されます。このパターンは、公開ホストサービスパターンと組み合わせて使用されることがよくあります。サプライチェーン管理システムは、明確で一貫したデータ交換を保証するために、JSONスキーマを使用したREST API経由でデータを公開します。

適切な統合パターンの選択

統合パターンの選択は、境界づけられたコンテキスト間の関係、モデルの安定性、各コンテキストに対する制御レベルなど、いくつかの要因に依存します。決定を下す前に、各パターンのトレードオフを慎重に検討することが重要です。

一般的な落とし穴とアンチパターン

境界づけられたコンテキストは非常に有益ですが、避けるべき一般的な落とし穴もいくつかあります：

• 泥だらけの巨大な塊：境界づけられたコンテキストを適切に定義できず、理解と保守が困難なモノリシックなシステムになってしまうこと。これはDDDが目指すものとは正反対です。
• 偶発的な複雑性：多すぎる境界づけられたコンテキストを作成したり、不適切な統合パターンを選択したりすることによって、不必要な複雑性を導入すること。
• 時期尚早の最適化：ドメインと境界づけられたコンテキスト間の関係を完全に理解する前に、プロセスの早い段階でシステムを最適化しようとすること。
• コンウェイの法則の無視：境界づけられたコンテキストを会社の組織構造と整合させないことによって、コミュニケーションや調整の問題を引き起こすこと。
• 共有カーネルへの過度の依存：共有カーネルパターンを頻繁に使用しすぎることによって、密結合と柔軟性の低下を招くこと。

境界づけられたコンテキストとマイクロサービス

境界づけられたコンテキストは、マイクロサービスを設計するための出発点としてよく使用されます。各境界づけられたコンテキストは、独立したマイクロサービスとして実装でき、独立した開発、デプロイ、スケーリングを可能にします。ただし、境界づけられたコンテキストが必ずしもマイクロサービスとして実装される必要はないことに注意することが重要です。より大きなアプリケーション内のモジュールとして実装することもできます。

境界づけられたコンテキストをマイクロサービスと組み合わせて使用する場合、サービス間の通信を慎重に検討することが重要です。一般的な通信パターンには、REST API、メッセージキュー、イベント駆動型アーキテクチャなどがあります。

世界中の実践例

境界づけられたコンテキストの適用は普遍的ですが、その具体的な内容は業界やコンテキストによって異なります。

• グローバルロジスティクス：多国籍ロジスティクス企業は、*出荷追跡*（リアルタイムの位置情報更新の処理）、*通関*（国際的な規制と書類の処理）、*倉庫管理*（保管と在庫の最適化）のために個別の境界づけられたコンテキストを持つ可能性があります。「品目」は、各コンテキストで非常に異なる表現を持つことになります。
• 国際銀行業務：グローバルな銀行は、*リテールバンキング*（個人顧客口座の管理）、*商業バンキング*（事業ローンと取引の処理）、*投資銀行業務*（証券と取引の処理）のために境界づけられたコンテキストを使用できます。「顧客」と「口座」の定義は、これらの領域全体で大きく異なり、多様な規制とビジネスニーズを反映します。
• 多言語コンテンツ管理：グローバルなニュース組織は、*コンテンツ作成*（記事の執筆と編集）、*翻訳管理*（異なる言語へのローカライズの処理）、*公開*（様々なチャネルへのコンテンツ配信）のために個別の境界づけられたコンテキストを持つことができます。「記事」の概念は、それが執筆されているか、翻訳されているか、公開されているかに応じて異なる属性を持ちます。

結論

境界づけられたコンテキストは、ドメイン駆動設計における基本的な概念です。境界づけられたコンテキストを効果的に理解し適用することで、ビジネスニーズに合致した、複雑でスケーラブルかつ保守可能なソフトウェアシステムを構築できます。境界づけられたコンテキスト間の関係を慎重に検討し、適切な統合パターンを選択することを忘れないでください。一般的な落とし穴やアンチパターンを避け、ドメイン駆動設計を習得する道を順調に進むことができるでしょう。

実用的な洞察

1. 小さく始める：すべての境界づけられたコンテキストを一度に定義しようとしないでください。ドメインの最も重要な領域から始め、学習が進むにつれて反復してください。
2. ドメイン専門家との連携：境界づけられたコンテキストがビジネスドメインを正確に反映していることを確実にするため、プロセス全体を通してドメイン専門家と連携してください。
3. コンテキストマップの視覚化：開発チームや利害関係者に対して、境界づけられたコンテキスト間の関係を伝えるためにコンテキストマップを使用してください。
4. 継続的なリファクタリング：ドメインの理解が深まるにつれて、境界づけられたコンテキストをリファクタリングすることを恐れないでください。
5. 変化を受け入れる：境界づけられたコンテキストは固定されたものではありません。変化するビジネスニーズや技術の進歩に適応する必要があります。